Blog
Wer sich bei allen beliebt machen will, wird schnell beliebig.
Wer sich bei allen beliebt machen will, wird schnell beliebig.
Ich habe mir kürzlich ein neues Notebook gekauft, von HP ein Elitebook 735 G5 mit AMD Ryzen 27000 CPU. Auf dem Gerät war Windows 10 Pro vor installiert, das ich auch haben wollte, primär arbeite ich aber unter Linux. Ich musste mir also zusätzlich noch ein Linux parallel installieren. Standardmäßig ist in dem Gerät eine 256 GB PCIe NVMe SSD verbaut. 256 GB sind für zwei Betriebssysteme samt jeweils vollständig installierter Entwicklungsumgebungen zu wenig, weshalb ich eine größere Festplatte verbaut habe (eine PCIe NVMe SSD von Samsung mit deutlich mehr Kapazität).
Um Windows 10 Pro auf der neuen Platte nicht neuinstallieren zu müssen wollte ich den Inhalt der alten SSD via „dd“¹ vollständig auf ein USB-Laufwerk sichern, dann die neue Samsung SSD einbauen und die Sicherung wieder via „dd“ auf die neue Platte rüber kopieren. Damit fing dann der Ärger an.
Zunächst musste ich das UEFI davon überzeugen von meinem USB-Stick zu booten, dafür war es erst einmal nötig „secure boot“ auszuschalten. Mit ausgeschalteten „secure boot“ konnte ich dann erfolgreich ein „Live Linux image“ booten, aber jeder Zugriff auf die SSD, um sie mit „dd“ zu sichern, wurde mit einer kryptischen Fehlermeldung verweigert. Nun dachte ich, das wird wohl an dem hoffnungslos veralteten „Live image“ (Ubuntu 14.04) liegen das mit Neuen PCIe SSDs möglicherweise nicht klar kommt und ich noch für meinen bootbaren USB-Stick benutzte. Ich hab nicht lang gefackelt und mir einen neuen bootbaren USB-Stick mit einem aktuellen Ubuntu angefertigt, aber das Problem blieb das gleiche.
Da ein neueres „Live Linux image“ das Problem nicht zu lösen vermochte, habe ich mich wieder in die untiefen des UEFI-Setups begeben, da habe ich das TPM-Modul deaktiviert und siehe da, jetzt konnte ich nicht nur vom USB-Stick aus booten, ich konnte auch von dem „Live image“ aus auf die interne SSD zugreifen und eine Kopie mittels „dd“ auf ein externes Wechsellaufwerk machen, so wie die Sicherung dann auf die neue SSD rüber kopieren.
Im nächsten Schritt habe ich dann mit dem gleichen „Linux live image“ die Windows Partition mithilfe von GParted auf ca. die hälfte der Größe der neuen SSD erweitert und dann im Anschluss auf dem restlichen freien Speicher ein aktuelles Xubuntu 18.04 installiert.
Die Installation von Xubuntu 18.04 verlief erst einmal völlig reibungslos, danach ging dann aber auch schon der nächste Ärger los. Bei diversen Neustarts hing sich das neue Notebook in aller Regelmäßigkeit beim Runter- und Hochfahren auf. Dabei ist die Kiste einfach eingefroren, weder gab es unter Windows einen Bluescreen, noch unter Linux eine „Kernel panic“². Ich ging erst davon aus, dass es möglicherweise an noch nicht korrekt installierten Treibern läge, und habe den passenden AMD Radeon Treiber³ von der AMD Webseite runtergeladen und installiert. Nach der Installation des Treibers und einem reboot sah soweit auch alles gut aus, der Treiber wurde korrekt geladen und ich konnte auch mittels „Steam“4 für Linux Spiele starten und laufen lassen (Hardware beschleunigt versteht sich). Die Ernüchterung kam dann nach dem nächsten Hochfahren, auf einmal wurde der Treiber nicht mehr geladen und Linux lief nur noch im VESA5 Modus. Ich spielte ein wenig in den Konfigurationen rum und merkte, das der Treiber mal sporadisch geladen wurde und mal nicht, ohne das ich zunächst dafür habe einen Grund ausmachen können. Ich nahm an, es läge möglicherweise am Treiber und installierte stattdessen den open source AMD Radeon Treiber, das Ergebnis war das gleiche, auch dieser wurde sporadisch mal korrekt geladen und mal nicht. Darauf hin fing ich an, im UEFI „rum zu spielen“, im Gedanken das Problem könnte hier liegen. Ich schaltete „secure boot“ und das TPM-Modul wieder ein; es half nichts. Nach einiger Zeit habe ich dann entnervt das UEFI in seine „Werkseinstellungen“ zurückversetzt (Was es meiner Meinung nach eigentlich schon war, denn mehr als „secure boot“ und das TPM-Modul habe ich nicht konfiguriert). Auf einmal wurde der Grafiktreiber korrekt geladen und das nicht mehr nur sporadisch. Beim Konfigurieren von „secure boot“ und dem TPM-Modul muss sich irgendetwas im UEFI-Setup „queer“ gelegt haben, dass mit dem harten Reset in die Werkseinstellung wieder grade gezogen wurde. Von nun an bootete das Notebook reibungslos und fuhr zumindest unter Windows auch korrekt runter. Nur unter Linux hing es beim Runterfahren für 10 Minuten, bis es sich dann ausschaltete (es hing beim Runterfahren der MySQL-Datenbank fest).
Irgendwann habe ich festgestellt, dass jeweils nach dem ich Windows gebootet habe, die Uhrzeit unter Linux nicht mehr stimmte und wenn ich Linux gebootet habe, dann die Uhrzeit unter Windows nicht mehr stimmte. Wie sich herausstellte beziehen beide Betriebssysteme ihre Uhrzeiten von einem Timeserver via NTP6 (was ja auch sinn ergibt) und stellten nach dem Booten und einloggen die Uhrzeit ein, aber nicht nur für sich, sondern systemweit in dem sie jeweils die Zeit im UEFI überschrieben. Das war wiederum für das aufhängen beim Runterfahren verantwortlich, und zwar durch ein Wechselspiel mit einer installierten MySQL Datenbank (da muss man erst einmal drauf kommen). Verursacht wurde die Misere weil systenmd7 den NTP daemon erst nach der MySQL-Datenbank startet, der NTP daemon hat dann seinerseits die Uhrzeit umgestellt, so das die MySQL-Datenbank in der Zukunft lief, was diese wiederum so aus dem Tritt brachte, dass sie beim Runterfahren festhing bis ein 10 Minuten timeout eingetreten ist und den MySQL Prozess beendet hat. Lösen konnte ich das Problem am Ende dadurch, dass ich das UEFI Passwort geschützt habe und somit dafür gesorgt habe, dass weder Windows noch Linux die Zeit im UEFI mehr überschreiben können.
Was ist das eigentlich für ein Rotz, dass ein Betriebssystem so einfach im UEFI rum schreiben kann? Wer hat sich diesen Misst nur ausgedacht? Das scheint mir dann alles doch keine so große Verbesserung zu den früheren BIOS Systemen zu sein, vor allem wirkt das alles sehr unausgereift und ich habe zweifel, ob sich daran sobald irgendetwas ändern wird. Auf mich macht es den Eindruck eines viel zu komplexen und damit fehlerträchtigen Systems.
1) dd
2) Kernel panic
3) AMD Radeon Treiber
4) Steam for Linux
5) VESA
6) NTP
7) systemd